home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7051 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.5 KB
  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c
  4. Subject: Re: Hungarian notation - whoops!
  5. Date: Wed, 21 Feb 96 13:39:02 GMT
  6. Organization: none
  7. Message-ID: <824909942snz@genesis.demon.co.uk>
  8. References: <30C40F77.53B5@swsbbs.com> <4fc157$jsf@goanna.cs.rmit.EDU.AU> <dewar.823793746@schonberg> <4fms62$c0p@goanna.cs.rmit.EDU.AU> <4ft1ruINN6dr@keats.ugrad.cs.ubc.ca> <4g9255$74s@goanna.cs.rmit.EDU.AU>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: genesis.demon.co.uk
  13.  
  14. In article <4g9255$74s@goanna.cs.rmit.EDU.AU>
  15.            ok@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes:
  16.  
  17. >Let me say it again:
  18. >
  19. >        C, like many programming languages, has two mathematically
  20. >        simple functions on ***SIGNED*** integers:
  21. >                -x
  22. >                abs(x)
  23. >        An implementation of C, or any other such language, using
  24. >        ones-complement or sign-and-magnitude arithmetic, easily
  25. >        delivers correct outputs for all legal inputs to these operations.
  26. >
  27. >        An implementation of C, or any other such language, using
  28. >        twos-complement arithmetic, EITHER delivers incorrect outputs
  29. >        for some legal inputs OR requires checking which is in practice
  30. >        seldom offered.
  31.  
  32. Checking against overflow is required whatever representation is used.
  33. Once this is established using 2's complement is no worse than any other
  34. representation.  Did you see my earlier reply in the thread on this subject?
  35.  
  36. If nothing else it seems to me that 2's complement is a big win with
  37. regards to implementing multiple-precision arithmetic since lower order
  38. bits of the result of most operations don't depend on the signs of the
  39. operands or the sign of the result.
  40.  
  41. >The practical consequence of this is that responsibility for ensuring that
  42. >the input to unary minus or absolute value is in range is passed onto the
  43. >programmer.  It is that which I am complaining about.  It doesn't make my
  44. >life as a programmer one teeny tiny bit easier.
  45.  
  46. It doesn't make it any harder either - see my earlier post.
  47.  
  48. >>The unsigned type is the ticket for portable integer modulo arithmetic.
  49. >
  50. >Modular arithmetic in Ada 95 *is* the ticket for portable hackery.
  51. >Unsigned arithmetic in C is indeed defined to be modulo 2**n for some
  52. >n, but the bounds on n are very very loose, and the price of portability
  53. >is much programmer-inserted masking.
  54.  
  55. Well, a small amount of masking.
  56.  
  57. >More importantly, while overflow in signed arithmetic is a run-time error,
  58. >unsigned arithmetic is very often a design-time error.
  59.  
  60. True, modulo arithmetic isn't useful in contexts where it simply generates
  61. the wrong result (however it does make it easy to test for overflow after
  62. an unsigned operation).
  63.  
  64. >For example, suppose I want to count the number of times some event occurs.
  65. >Unless I can *prove* at design time that the event can occur no more than
  66. >65535 times, use of 'unsigned int' in C is a design-time error.
  67.  
  68. Only if the code doesn't test for wrap to zero. Unsigned types make this
  69. test very easy.
  70.  
  71. > There is
  72. >at least one "commodity ISA" with a 300Mhz implementation getting close.
  73. >How long is a 32-bit unsigned counter usable with 3e8 events per second?
  74. >
  75. >A little over 14 seconds.
  76.  
  77. True, it has become important that contemporary languages mandate support
  78. for types longer than 32 bits.
  79.  
  80. >Overflows aren't the problem.  Restricted machine arithmetic is the problem.
  81.  
  82. It depends on where you put the limit. Language support for multiple-precision
  83. arithmetic or specified precision beyond 64 bits (or possibly 128 bits)
  84. has some uses but they are rare across the whole spectrum of code.
  85.  
  86. >>If you
  87. >>don't allow any sort of unaligned access, allowing only contiguous 32-bit
  88. > words
  89. >>to be accessed individually, you force size N arrays of characters to be 4N
  90. >>bytes long. That is seen by some people as a waste of memory. 
  91. >
  92. >You are confusing *unaligned* access with *byte* access.  Like it or not, it
  93. >is a fact that the machines I was talking about DID support byte access,
  94. >DID support packed arrays of character, but did NOT support unaligned
  95. >access.
  96.  
  97. And there are yet other systems (e.g. Crays) which don't support byte access
  98. but compilers can still support characters arrays where the character unit
  99. is smaller than the machine word unit by bit twiddling tricks.
  100.  
  101. -- 
  102. -----------------------------------------
  103. Lawrence Kirby | fred@genesis.demon.co.uk
  104. Wilts, England | 70734.126@compuserve.com
  105. -----------------------------------------
  106.